SAD Ch 13

the processes that are responsible for the input side of the transformation equation.

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.

the term used in reference to the processes responsible for actual transformation of data.

cohesion in which modules have instructions that bear little or no relationship to each other.

a term used in reference to two modules that both refer to the same global data area.

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.

the condition that occurs when one module actually modifies the procedural content of another module.

coupling in which one module passes control information or flags to another module.

data used or generated as a function of controlling the speed, duration, or timing of a process.

coupling in which the dependency between the two modules is limited to the fact that they pass data between each other.

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").

program-level details that describe the exact set of instructions necessary to control a given input or output; normally not shown on the DFD.

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.

a group of files that contain instruction sets that may be used by a variety of program modules.

the output-side processes

the logical flow of event associated with thte detection or correction of a user error.

breaking down the system into a set of functional modules of manageable size and relationships.

cohesion in which modules are designed such that their instructions work collectively to accomplish a single well-defined task or function.

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.

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.

condition that occurs when a subordinate module has been designedd to pass control to a suberordinate module.

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.

a condition in which modules are almost completely independent.

a design condition in which a single module does not have control over more than five to seven subordinate modules.

an approach to software design that decomposes a large, complex software application into smaller, interrelated components called modules.

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.

a measure of completeness.  Every statement in a module should relate to the identified function of that module.

the extent to which two or more program modules are interdepentent.

the number of subordinate modules that a single module can effectively control.

the condition in which all processes contained on th eDFD perform only one function.

a collective term for the processes that take the product of the central process and prepare it for display to the end user.

cohesion in which the instruction set in a module performs multiple functions that have a specific sequence in which they must be performed.

the logical format or layout of program code; normally not shown on a DFD.

a programming procedure in which the same operation is repeated or "looped" a specified number of times.  Also called a loop.

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.

the number of direct report employees a manager can effectively manage.

coupling in which data are passed between modules in the form of data structures or entire records.

the top-town approach to systems development using modules; formalized into a workable strategy by Yourdon and Constantine.

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.

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.

any data that do not need to be communicated to the other module for the function to successfully execute.

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.

processes on the DFD that can be categorized as being directors of the data flow to subordinate processes that actually perform the calculations.

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.

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.