L 5 System design functional decomposition Bottomup and

L 5: System design: functional decomposition • • Bottom-up and top-down design Functional decomposition Case study Coupling and cohesion

Bottom-up vs. top-down • Bottom up – Given constituent parts – Develop a working system • Build modules to accomplish specific tasks • Integrate modules together into working system 3 – For example • Given a supply AND, OR and NOT gates • Build a computer 2 – Pros • Leads to efficient subsystem • Allows more creativity, “what if” questions – Cons • Complexity is difficult to manage • Little thought to designing reusable modules • Redesign cycles 1 1

• Top down – Similar to the concept of divide and conquer – Relies on vertical thinking – Given the specification of a system 1 • Develop a working system – Divide the problem into abstract modules – Reiterate until constituent parts are reached – Pros • Particularly valuable in large projects • Highly predictable design cycle • Efficient division of labor – Cons • Limits the solution space and innovation • More time spent in planning 2 2 3

Functional decomposition • Recursively divide and conquer – Split a module into several sub-modules – Define the input, output, and behavior – Stop when you reach realizable components • The end result is a functional block diagram – A block diagram that describes the functions in the system and their interrelations 3

• Guidance for implementing functional decomposition – It is an iterative process • Some details are unknown until implementation time, so you may need to iterate, alternate top-down and bottom-up, and adjust the design later – – – – – 4 Upfront time saves redesign time later Sub-modules should have similar complexity Precise input, output, and behavior specifications* Look for innovation Don’t decompose ad-infinitum Use suitable abstraction to describe sub-modules Look at how it has been done before Use existing technology Keep it simple *The details are not the details. Communicate results They make the design –Charles Eames

Example: Thermometer Design • The system must – – – 5 Measure temperature between 0 and 200°C Have an accuracy of 0. 4% of full scale Display the temperature digitally, including one digit beyond the decimal point Be powered by a standard 120 V 60 Hz AC outlet Use an RTD (thermal resistive device) that has an accuracy of 0. 55°C over the range. The resistance of the RTD varies linearly with temperature from 100Ω at 0°C to 178Ω at 200°C

Level 0 • Module Digital Thermometer Inputs - Ambient temperature: 0 -200 C - Power: 120 V AC power Outputs - Digital temperature display: A four digit display, including one digit beyond the decimal point Functionality - Displays temperature on digital readout with an accuracy of 0. 4% of full scale 6

• Level 1 – We only shown one module’s functionality –see textbook for the rest Module Temperature Conversion Unit Inputs - Ambient temperature: 0 -200 C. - Power: ? V DC (to power the electronics) Outputs - VT: temperature proportional voltage. VT= αT, and ranges from ? to ? V Functionality - Produces an output voltage that is linearly proportional to temperature. It must achieve an accuracy of ? % 7 Notice there are unknowns at this early stage

Examples of functional block diagrams ADIS 16203 programmable 360° incline-angle measurement system http: //www. analog. com/static/imported-files/data_sheets/ADIS 16203. pdf 8

Magellan Space Flight System http: //www 2. jpl. nasa. gov/basics/bd. php 9

Samsung GT-i 8510 INNOV 8 smartphone https: //www. diagramanual. com/samsung-gt-i 8510 -innov 8 -service-manual/ 10

Coupling and cohesion • Coupling – The extent to which modules are connected – Why avoid highly coupled systems? • Failure in one module propagates through the system • It is hard to redesign one module without affecting the others • With low coupled systems, however, reutilizing modules is hard – Two ways to reduce coupling • Minimize number of connections between modules • Maximize cohesion within modules • Cohesion – Refers to how focused a module is –highly cohesive systems do one or a few things very well – You should aim to design modules with a single well-defined objective – Why? It is easy to test modules independently later on 11