SAD Ch 13

  1. afferent processes
    the processes that are responsible for the input side of the transformation equation.
  2. bottom-up approach
    a method of system factoring that identifies the processes that need to be a part of the system and then moves forward to code each identified process as a module that interfaces with all other identified process modules.
  3. central transform
    the term used in reference to the processes responsible for actual transformation of data.
  4. coincidental coheision
    cohesion in which modules have instructions that bear little or no relationship to each other.
  5. common coupled
    a term used in reference to two modules that both refer to the same global data area.
  6. communicational cohesion
    cohesion in which a module is designed such that its instructions accomplish tasks that use the same piece of data but the sequencde of those instructions is not critical to a successful outome.
  7. content coupling
    the condition that occurs when one module actually modifies the procedural content of another module.
  8. control coupling
    coupling in which one module passes control information or flags to another module.
  9. control data
    data used or generated as a function of controlling the speed, duration, or timing of a process.
  10. data coupling
    coupling in which the dependency between the two modules is limited to the fact that they pass data between each other.
  11. data flow decision points
    branches in the flow of data as a result of a decision outcome (e.g., "'Is it Monday:' If 'Yes' go to Process 1.7, if 'No' go to Process 1.9").
  12. detailed input/output operations
    program-level details that describe the exact set of instructions necessary to control a given input or output; normally not shown on the DFD.
  13. dynamic data exchange (DDE)
    a common example of good data-coupled module design that can be found in the Microsoft Windows environment.  It allows multiple Windows programs to share the same data.
  14. dynamic link library (DLL)
    a group of files that contain instruction sets that may be used by a variety of program modules.
  15. efferent processes
    the output-side processes
  16. error path
    the logical flow of event associated with thte detection or correction of a user error.
  17. factoring
    breaking down the system into a set of functional modules of manageable size and relationships.
  18. functional cohesion
    cohesion in which modules are designed such that their instructions work collectively to accomplish a single well-defined task or function.
  19. hierarchical structire diagram
    a diagram that illustrates the relationship of the modules to each other and displays the flow and processing of data between and within the various modules of the system in hierarchical form.  Also known as a structure chart.
  20. input stream
    a collective term for the processes preceding the central process, which are primarily responsible for generating the required input in the appropriate form for the central process.
  21. inversion of authority
    condition that occurs when a subordinate module has been designedd to pass control to a suberordinate module.
  22. logical cohesion
    cohesion in which the instructions are related to each other only because they appear to fall into the same logical class of functions, such as editing or mathematical computation.
  23. loose coupling
    a condition in which modules are almost completely independent.
  24. low fan-out
    a design condition in which a single module does not have control over more than five to seven subordinate modules.
  25. modular design
    an approach to software design that decomposes a large, complex software application into smaller, interrelated components called modules.
  26. module
    a group of executable instructions with a single point of entry and a single point of exit; designed to perform its functions independently from all other modules contained within the application.
  27. module cohesion
    a measure of completeness.  Every statement in a module should relate to the identified function of that module.
  28. module coupling
    the extent to which two or more program modules are interdepentent.
  29. module span
    the number of subordinate modules that a single module can effectively control.
  30. monofunctionality
    the condition in which all processes contained on th eDFD perform only one function.
  31. output stream
    a collective term for the processes that take the product of the central process and prepare it for display to the end user.
  32. procedural cohesion
    cohesion in which the instruction set in a module performs multiple functions that have a specific sequence in which they must be performed.
  33. program structure
    the logical format or layout of program code; normally not shown on a DFD.
  34. repetition
    a programming procedure in which the same operation is repeated or "looped" a specified number of times.  Also called a loop.
  35. sequential cohesion
    the relationship between one instruction and the next in a given module.  Such modules have instructions that are related to each other such that the result, or output, of one instruction becomes the input for the next instruction.
  36. span of control
    the number of direct report employees a manager can effectively manage.
  37. stamp coupling
    coupling in which data are passed between modules in the form of data structures or entire records.
  38. structured design
    the top-town approach to systems development using modules; formalized into a workable strategy by Yourdon and Constantine.
  39. temporal cohesion
    cohesion in which the sequence of the instructions does not matter.  The logic behind grouping the instructions into a single module is that they all need to execute at about the same point in time, such as during program initialization or shutdown.
  40. top-down approach
    a method of system factoring in which the system is first viewed in the broadest possible sense and then decomposed into subsystems that work together to efficiently and effectively reach the stated objectives for the overall system.
  41. tramp data
    any data that do not need to be communicated to the other module for the function to successfully execute.
  42. transaction analysis
    an approach to the development of a structure diagram in which the analyst examines the DFD for the purpose of identifying processes that represent transaction centers.
  43. transaction centers
    processes on the DFD that can be categorized as being directors of the data flow to subordinate processes that actually perform the calculations.
  44. transform analysis
    an approach to the development of a structure design in which the analyst examines the DFD and divides the various processes into three categories: those that perform either input or input editing functions, those that actually perform calculations or process data, and those that serve to create or finalize system output.
  45. utility modules
    additional modules and data couples to provide functionality associated with getting input via the user interface; reading, writing, modifying, and deleting data stores; and generating formatted output data or reports.
Card Set
SAD Ch 13
Systems Analysis & Design