1. Systems Design

2.  Application Design  User Interface Design  Database Design

3.  Factor: The system should be factored or decomposed into small modules that conform the size and cohesion guidelines of good design.  Span of control : No parent modules should be given control over more than five to seven child, or subordinates, modules.  Coupling : The extent to which modules are dependent on each other should be minimized.  Size: A reasonable size for a single module is considered to be between 50 and 100 lines of executable code.  Cohesion : The instructions within a module should pertain only that function.  Shared use : Wherever possible, a child module should be called by multiple parent modules.

4.  A single program usually cannot perform all of the required functions  One of the most widely accepted approaches to application design is called modular design or structured approach, which is based on the concept of functional decomposition. This approach decomposes a large, complex software application into smaller, interrelated components called modules.  A module is defined as a small section of program code that carries out a singe function. It is a group of executable instructions with a single point of entry and a single point of exit.

5.  A module is designed to perform its function independently from all other modules contained within the application.  Different functions are performed by different modules/programs. These functions/modules form the entire system.  The various functions of the application are executed by either a single module or a series of modules where the currently executing module may call on one or more modules to perform a particular task.

6.  Programs written in third language such as Visual Basic, C etc. are organized in ◦ modules which are arranged in a hierarchy like a tree.  The application design is specified with a structure chart.

7.  The inputs for the development of the design models and documents are the data flow diagrams and their detailed documentation.  Analyst use an intermediate form of the DFD called the DFD with automation system boundary, which divides the computerized portions of the system from the manual portions.

8.  The data flows are found inside, outside or crossing the system boundary and the program boundaries.  Data flow crossing the system boundary represent inputs and outputs of the system.  Design of the program interface including both the user interface and the transmittals to other system is defined by the boundary-crossing data flows.  These data flows that cross the boundaries between programs represent program to program communication.  Data flow will be forms or reports in the user interface or files or telecommunication transmittals between system.

9.  Primary objective of structured Design: to create a top-down decomposition of the functions to be performed by a given program in a given  Using structure chart techniques always provides a hierarchical organisation of program functions.

10.  The processes appearing on DFD may directly translate into modules on a structure chart.  The level of details in DFD is insufficient for programmers to effectively do their jobs.  The DFD does not show error paths, repetitions or loops, control data, data flow decision points, detailed input/output operations or program structure.  Different symbols are used to depict certain critical actions to the programmer.

11.  A structure chart hierarchy describes the functions and the sub functions of each part of the system.  Example ◦ A program may have a function called Calculate pay amounts. Some sub functions are Calculate base amount, Calculate overtime amount and Calculate taxes.  In a structure chart, these functions are drawn as a rectangle. Each rectangle represents a module.

12.  Modules are relatively simple and independent components.  Modules are well formed with high internal cohesiveness and minimal data coupling.  Types of modules:  Higher-level modules are control modules that control the flow of execution. ◦ Top module- also called boss or main module ◦ Middle level module – also called control module  Lower-level modules are “worker-bee” modules and contain the program logic to actually perform the functions. ◦ Leaf module – modules at the end of the branches.

13.  Rectangle: represents a module, which can be a function, procedure or subroutine. A modules also can be separately compiled entity such as a complete C program.  Example ◦ The calculate pay amounts module call the lower level modules in the correct sequence to carry out the logic of calculating payroll. Symbols used in Structure Charts Module 1

14. Module 1.2 Module 1.1 Module 1.2 Module 1.2.1 Main or boss module Control modules Worker modules

15.  The lines connecting the modules indicate the calling structure from the higher level modules to the lower level modules.  The little arrows next to the lines shows the data that are passed between modules and represent the inputs and outputs of each module.

16.  Rectangle with double bars:  This is a library module, which is reusable code and can be invoked from more than one point in the chart i.e. used in several places. Module 1 Module 1.2Module 1.1 Module 1.3

17.  A program call: Data passed between modules. It occurs when one module invokes a lower level module to perform a needed service or calculation. The program passes control to the called module, the called module executes a series of program statements, then the called program passes control back to the calling module and execution resumes with the statement or instructions immediately following the call. The arrows from the higher level modules to the lower level modules indicate the program call.  The direction of the call is always from left to right.

18. Data Couple: The arrow with the empty circle, called data couples, represent data being passed into and out of the module. ◦ A data couple can be an individual data item such as a customer account number or a higher level data structure such as an array, record or other data structure. ◦ Coupling between the modules near the top of a structure chart typically consists of data structures representing high level aggregation data. ◦ Coupling between modules at the bottom of the structure chart typically consists of single data items, flags etc.

20.  Control couple: ◦ An arrow with a filled circle represents a control couple. A control couple shows a message, also called a flag, which one module sends to another.

22.  Loop: ◦ A curved arrow represents a loop. A loop indicates that one or more modules are repeated. In the following example, the Get Student Grades and calculate GPA modules are repeated.

24.  Conditional calling of low-level modules – i.e.  A line with a diamond on one end represents a condition. A condition line indicates that a control module determines which subordinate modules will be invoked, depending on a specific condition.  Example:  Sort Inventory Parts is a control module with a condition line that triggers one of the three subordinate modules.

26.  Cohesion measures a module’s scope and processing characteristics. A module that performs a single function or task has a high degree of cohesion, which is desirable. Because it focuses on single task, a cohesive module is much easier to code and reuse e.g. a module named Verify Customer Number is more cohesive than a module name Calculate and Print Statements, because the word and in the module name means more than one task is involved. If a code performs multiple tasks, more complex coding is required and the module will be more difficult to create and maintain.

27.  To understand cohesion, remember process modelling.  To create a levelled set of DFDs, identify processes, and then break the processes down into functional primitives that performed a single task. Then translate those functional primitives into cohesive modules. If you need to make a module more cohesive, you can split it into separate units, each of which performs a single function.

29.  Coupling describe the relationships and interdependence among modules.  Modules that are independent are loosely coupled, which is desirable.  Loosely coupled modules are easier to maintain and modify, because the logic in one module does not affect other modules.  If a programmer needs to update a loosely coupled module, he or she can accomplish the task in a single location.  If the modules are tightly coupled, one module refers to internal logic contained in another module.

33.  If you need a structured analysis method, your structure charts will be based on the DFDs you created during data and process modelling. The following are the steps used for creating a structure chart. Step 1:Review the DFDs: Review all DFDs for accuracy and completeness, especially if changes have occurred since the systems analysis phase.

35.  Steps 2:Identify Modules and Relationship  Working from the logical model, you transform functional primitives into program modules. When analyzing a set of DFDs, each DFD level represent a processing level. If you using the DFDs, starting from the context diagram to the lower level diagrams, identify control modules and subordinate modules, until the functional primitives are reached.  If more cohesion is desired, divide the process into smaller modules that handle a single task.

36.  Step 3:Add Couples, loops and conditions  Review the data flows to identify the data elements that pass from one module to another.  Add the control couples where a module is sending a control parameter, or flag to another module.  Add loops and condition lines that indicate repetitive or alternative processing steps.

38.  Step 4:Analyze the Structure Chart and the data Dictionary  Check each process, data element to ensure that the chart reflects all previous documentation and that the logic is correct. Determine that modules are strongly cohesive and loosely coupled.

39. Structure Chart Example No. 2