1. Chapter 9 Moving to Design

2. The Structured Approach To Designing The Application Architecture Module-an identifiable component of a computer program that performs a defined function Computer program—a set of modules that are compiled into a single executable entity System flowchart– a diagram that describes the overall flow of control between computer programs in a system Pseudocode– structured-programming-like statements that describe the logic of a module

3. The Automation System Boundary Partitions the data flow diagram processes into manual and automated processes Processes outside the system boundary are manual processes (eg., enter customer orders, inspect reports, etc) Processes that are inside the system boundary may be carried out on-line or in batch mode data flows are found inside, outside, or crossing the system boundary and the program boundaries. Data flows that cross the system boundary represent input and outputs of the system.

4. The System Flowchart Process or program File of Database Document or report File on Magnetic tape Input of output screen display

5. System Flowchart Manual Operation Communication between components Communication Link

6. The Structure Chart A hierarchical diagram showing the relationships between the modules of a computer program Program call—the transfer of control from a module to a subordinate module to perform a requested service Data couples –the individual data items that are passed between modules on a program call

7. Developing a Structure Chart Transaction analysis—the development of a structure chart based on a DFD that describes the processing for several types of transactions Transform analysis –the development of a structure chart based on a DFD that describes the input-process-output data flow Afferent data flow –incoming data Efferent data flow– outgoing data flow Central transform – set of DFD processes that are located between the input and output processes.

8. Evaluating the Quality of a Structure Chart Module coupling –the manner in which modules relate to each other (data coupling is preferred) Module cohesion – a measure of the internal strength of the module It is most desirable to have highly cohesive and loosely coupled modules

9. Coupling A measure of how a module is connected to the other modules in the program Objective– make the modules as independent as possible.

10. Cohesion The degree to which all of the code within a module contributes to implementing one well- defined task. Modules that implement a single task tend to have relatively low coupling because all of their internal code acts on the same date item(s) A flag passed down the structure chart is also an indicator of poor cohesion in the low-level module.

11. The Object-Oriented Approach