issues to be addressed when defining the problem
- requirements of the solution
- possible/cost-efficient??
- constraints vs resources available
- similar existing solutions
- team’s skill level
performance requirements
list of requirements for the solution
- can become more specific set of specification under which the final product can be evaluated
main aspects of defining the problem
- understanding crucial details
- inputs + outputs + processing
- steps the solution must have
- specifications of solution from client
how to structure inputs and outputs
context diagram: level 0 data flow diagram which shows all external inputs + outputs
how to structure steps of a solution
IPO diagrams: input –> processing –> output
- shows all inputs, processes, and outputs and decides nature of processing
how to decide nature of processing
- consider a smaller version of the problem
- related/similar problems
- breaking down the problem
- brainstorming possibilities
how to plan + design software solutions
- systematic breakdown
- think of nature of data + data structures
- design solution + algorithms
abstraction
taking away/separating part of the problem/solution so that it can be considered in isolation
done through: breaking up solution into manageable modules
why is abstraction good
- encourages reusable modules of code
- simplifies testing process
refinement
the process of developing a hierarchy of sub-routines
why is refinement good
- each high-level routine can access/call one or more low-level sub-routines
- code may not be reusable, but tailored to the specific problem
system modelling tools
system model: representation of system; specifications to developers, structure + functionality
system flowcharts
- demonstrates logic = flow of data through system
- high-level, provides overview of the whole system
data flow diagrams
- describes the flow data takes through the system
- no timing of events indicated
- data stores: repositories for data, can be physical or digital
- external entities: = terminators, starting + ending points
structure charts
- used to model hierarchy of subroutines + sequence in which they take place
- flow of data + data movements for clarity
- top-down design most popular, with decisions + repetitions included
- primary functions: top to bottom, left to right describing sequence
data types
raw material, stored in binary
binary
- base 2, 0 + 1
- yes or no, on or off
- based off transistors with only two states; on and off
- 8 bits = byte
- meaning dependant on context
common predefined data types
- integer
- floating point
- string
- boolean
- date
- currency
integer
- positive or negative
- WHOLE NUMBER!!
- no fractional values
- no. of bytes indicate range of integers which can be stored
- if a value outside the range is stored, will be mistype error
- calculations = fast + accurate
floating point
- real numbers: fractional + large values
- the larger the number, the slower the processing + more storage needed
- single precision: 32 bits
- double precision: 64 bits
- possible inaccuracies + high processing demands
string
- text data
- fixed length string: a string with a max. length
- dynamic length string: a string with no max. length
- unicode: universal code with everything
boolean
- logical data
- true or false(yes or no)
- only two possible states
- 1 bool = 1 bit
- commonly used to signal whether section of code has been executed or not
what is a subroutine
a set of statements that performs a single logical task
what is a module
a group of subroutines that achieve a subtask
