Skip to content

CH8: Process Oriented Design

Definitions

  • The main goal for structured design: to map the functional requirements into hardware and software environments.
  • The result of structured design is a:
    • programming specifications and plans for testing,conversion, training and installation.
    • prototype of part/all of the application.
  • Partitioning and functional decomposition are the basic activities used in dividing processes into modules.
  • IPO: input, process, output.
  • CIPO: control, input, process, output.
  • DFD: data flow diagram.
  • principles of good structured design:
    • information hiding: you have only access to the exact information you need to do your job.
    • modularity: design small self-contained modules that can be combined to form a larger system.
    • coupling: interdependence between modules, measure inter-module linkage.
    • cohesion: the degree to which the elements of a module are related to each other, the modules has the right amount of elements (not too many, not too few). measure intra-module strength.

activities of structured design

  • The major activities of structured design are:

    1. Transform or transaction analysis of DFD.
    2. refine and complete structure chart
    3. identify load units and program packages
    4. defines the physical database
    5. develope program specifications

  • stepwise refinement: defining functions that will accomplish a process, includes definitions of modules, programs and data.

  • program morphology: the program shape, fan-in, fan-out, scope of control, scope of effect.
  • data structure: definition of data in an application, includes logical data definitions and physical data structures.
  • abstraction: attention to some level of generalization without regard to irrelevant low level details.
  • partitioning:
    • the divide and conquer strategy used to divide subprocesses from DFD into groups for implementation.
    • has 2 methods: transformation analysis and transaction analysis.
  • transform analysis:
    • identifying clusters (partitioning) of subprocesses based on: input, output, transform-oriented.
    • afferent flows: flows inwards, reads data and prepare it for processing.
    • efferent flows: flows outwards, writes data to the database, displays or prints data.
    • central transform: the major function that transforms input state into output state.
    • examples: accounting, personnel, order-entry, inventory applications.
  • transaction analysis:
    • partitioning based on the transaction type.
  • structure chart :
    • is a hierarchic, input-process-output view of the application that reflects the DFD partitioning.
    • rectangle: process, diamond: decision, parallelogram: input/output.
    • example: https://imgur.com/KVEdHXl.png
  • Factoring is the process of decomposing a DFD into a hierarchy of program components that will eventually be programmed modules, functions, or control structures.
  • Data couples identify the flow of data into and out of modules and match the data flows on the DFD
  • Control couples identify the flow of control in the structure.

Balance in the hierarchy

  • Balance in the hierarchy (structure diagram) is determined by analyzing:
    • the depth of the hierarchy:
      • the number of levels in the hierarchy (diagram).
      • too many levels = too much communication overhead and not enough real work is taking place.
      • example: https://imgur.com/WpF36WE.png
    • the width of the hierarchy:
      • the number of modules that reports to each superior, higher level module.
      • fan-out:
        • number of subordinate modules that this module talk to (communicate with).
        • too much fan-out = processing bottleneck, module is controlling too much.
        • 7+-2**rule: number of fan-out should be between **5 and 9.
        • example: https://imgur.com/JfzdJKA.png
      • fan-in:
        • number of superior modules that talk to this module.
        • fan-in is desirable, when it identifies reusable modules.
        • example: https://imgur.com/JMKx8tn.png
    • the skew of modules:
      • the measure of balance in the structure chart.
      • skew happens when one of the high-level modules has more subordinate modules than the others.
      • if chart is skewed = incorrect factoring, but if we are 100% that factoring is correct, then this big module is driver module.
      • input-bound app: the skew happens in the input side, app is input-driven.
      • output-bound app: the skew happens in the output side, app is output-driven.
      • i/o-bound app: the skew happens in the central processing side of the app, app is process-driven.
      • example: https://imgur.com/S6Poop0.png
    • the span of control: synonym to the width of the hierarchy.
    • the scope of effect:
      • the number of modules that are conditionally processed based on decisions by this module.
      • high scope = fan-out, fan-in and coupling.
      • ideal scope = 0 or 1.
    • the levels of coupling and cohesion:
      • each discussed separately in the next sections.
      • coupling and cohesion are inversely proportional. if cohesion is high, coupling is low, and vice versa.

alternatives to structure charts

Physical database design