Lecture Notes for CS 325

Functional System Design, 14 February 2001


  1. design is a two part process

    1. construct the solution structure - architecture

    2. specify the details of the solution structure - data structures, control decisions, module behavior

  2. architectural description - structure charts

    1. a boxes-and-arrows diagram for system architecture

    2. each box is a behavioral abstraction

      1. hierarchal relation - super-ordinate, subordinate

    3. arrows represent calls-on or delegates or uses relations among boxes

    4. control and data flow indicated by labeled arrows

    5. non-specific control flows - iteration and decision

  3. system specification

    1. filling in the details for architectural design

    2. communicates the design to all interested parties

    3. components

      1. problem specification

      2. major data structures

      3. module behaviors

      4. design decisions

  4. modularity

    1. partitioning architecture into components

    2. simplify component behavior

    3. simplify inter-module communication - the basic trade-off

    4. construct independent modules

    5. abstraction guides partitioning

    6. partitioning strategies - top down or bottom up

      1. top down

        1. start at the top and partition into lower-level concepts

        2. stepwise refinement

        3. good for exploring unfamiliar problems and solutions

        4. works with under specified problems

      2. bottom up

        1. start at the bottom with simple, well-defined concepts

        2. build up to the problem solution

        3. good for building known systems by exploiting past solutions

        4. problem must be defined and stable

  5. design method

    1. how to come up with the solution model described by boxes and arrows

    2. structure design methodology - tied to data-flow diagrams

      1. transformational point of view - inputs going to outputs

      2. factoring - relying on subordinates to get the job done

      3. step 1 - draw the dfd

      4. step 2 - identify the most abstract transformation; make it the root

      5. step 3 - identify the root's subordinates (factor) establish the data flow and gross control flow

      6. step 4 - recurs on the subordinates

    3. design rules of thumb - guidance for developing the solution module

      1. coupling and cohesion - low coupling, high cohesion

      2. module size - smaller is generally better

      3. fan-in and fan-out - high fan-in may be good, high fan-out may be bad


This page last modified on 19 February 2001.