2.1.2 Thinking Ahead

• identifying preconditions of a system ; inputs outputs and reusable components • by thinking ahead, developers can build programs that are easy and intuitive to use

• include any data required to solve the problem • these are entered into the system by the user consider data structure and data types involved

• are the results that are passed back • outputs are produced once inputs have been processed / are essentially the solution to the problem

• visual onscreen information/ printed data • audio • haptic feedback • data to be input into another process or system

• designers begin by considering outputs based on the users requirements • the outputs are then used to identify the inputs required + how they need to be processed to produce the output

• requirements which must be met before the program can be executed • preconditions can be tested for within the code or included In the documentation for a particular library, subroutine or program

• including preconditions within documentation reduces the length and complexity of the program and saves time spent on debugging and maintenance • preconditions make subroutines more reusable

• requirements for the device specification to be able to run the program • the operating system required to run the program • any necessary additional software is hardware

• the parameter list must not be empty, otherwise index out of bounds error will occur • the data may need to be all of the same data type - otherwise invalid results may be returned or invalid comparisons made • actions need to be validated to ensure that they will not crash the program if erroneous results are returned

• commonly used functions which are packaged into libraries for reuse [1] • Reusable components include : • classes/objects [1] • subroutines eg. Functions and procedures [1] • abstract data structures e.g stacks and queues

• programmers make use of reusable components when developing large programs by : • designing software that is modular by breaking the problem into smaller manageable modules [1] • examples of modular components include objects and functions [1] • modules/modular components can be imported and reused in new software projects [1] • or modular components can be shared at runtime through program libraries [1]

• modules are reliable and bug free as they have already been thoroughly tested [1] • thus reusing tested modules leads to more reliable programs [1] • utilising reusable modules reduces development time [1] • as the programs can be shorter since the modules do not have to be rewritten + have already been tested [1] • and modules can also be shared [1]

• storing frequently used data/instructions in cache in case it is needed again [1] • allowing faster access for future use as it saves time of retrieving instructions from secondary storage again [1] • e.g frequently accessed webpages are cached so content can be loaded quicker

• frequently accessed webpages are cached so content can be loaded quickly and this frees up bandwidth for other tasks on a network e.g any images and text do not need to be downloaded every time the page is visited • caching provides faster data retrieval by storing freq accessed data in the cache for quick access • reduces load on servers and frees up network bandwidth by minimising repetitive data fetching

• when caching algorithms predict which instructions are likely to be soon fetched or required by a program and these instructions/data are loaded and stored in cache • this minimises delays waiting for data or instructions to be fetched from storage • however prefetching is limited by the accuracy of the algorithms used as data stored in cache is not always used

• smaller caches limit how much data can be stored • larger cache takes longer to search