Systems Analysis & Design: Topic 10
Structured design -- a procedure for creating the blueprints for a system that is effective, usable, reliable, and maintainable.
There are several guidelines we follow to create an easily maintained system:
Create Small, unique tasks that perform only one function.
- By creating small modules, we limit the complexity that can exist in any one of them, thereby making the modules easier to understand.
- This is critical for the maintenance programmer; the less time that must be spent figuring out the logic, the faster a change can be made.
Create Independent modules.
- This helps to isolate any changes or defects that we introduce since the only connection with other modules is through inputs and outputs of a prescribed format.
- If inputs and outputs are unchanged, we should be able to make a change within one module without affecting any others.
- This minimizes what is known as the ripple-effect in which one change creates new bugs, which when fixed create new bugs, which when fixed create new bugs, and so on.
Isolate the physical detail in lower-level modules.
- As the DFDs evolve into hierarchical structure charts, we try to put the policy-oriented, or logical, decisions in the upper modules and the more physical details in the lower ones.
- The physical details are more likely to change; for example, it is common to have to modify a couple of fields on a report or input record.
Build in flexibility.
- Set up a system that will accommodate a wide range of situations without the necessity of modifying the programs.
- For instance, if the names of all of a hospital's doctors were hard-coded into its programs, reprogramming would be necessary each time a doctor left or a new one joined the staff.
- A better solution would be to use a database of doctors' names which allows names to be changed at will by data entry staff without the intervention of the programming staff.
Strive for simplicity.
- One of the best ways to develop an easily maintained system is to make it the simplest possible system.
- The simple yet elegant solution results in an economy that is hard to beat both in creation and in maintenance.
Top-Down Design and Modular Development
- A top-down approach moves from the general to the specific.
- Top-down design allows the systems analyst to determine overall organizational objectives first, and then to divide the system into subsystems and their requirements.
- A modular approach involves breaking the system into logical, manageable portions, or modules.
- It helps to emphasize the interfaces between modules.
- Each module should be functionally cohesive, so that it is responsible for accomplishing only one function.
- Modules are easier to write and debug because they are virtually self-contained.
- Modules are easier to maintain -- scope of modifications is limited.
- Modules are easier to understand because they are self-contained subsystems.
- keep each module to a manageable size.
- pay attention to critical interfaces (data and control variables that are passed to other modules).
- minimize the number of modules that must be modified when making changes.
- maintain the hierarchical relationships established through the top-down approach.
Coupling -- Measure of the association or strength of the interconnections between functions. Weak coupling is better--a module's only connection with other modules should be through the parameter list.
Cohesion -- Measure of the relationships among the source statements within a module, or a measure of how closely the statements are related. The higher the cohesion, the better the module. A module should perform a single task only.
Module size -- The entire module should be easily envisioned. Limit to one page of code.
Interface redundancy -- If there is any redundancy in the parameter list it must be eliminated. example-positive or negative movement for elevator car along with up or down flag.
Fan-in -- This refers to the number of unique superordinate modules that call another module. Higher fan-in reduces redundant code, so it is better, as long as it does not increase complexity.
Fan-out -- This refers to the number of unique subordinate modules that are called by a module. Three to nine is preferred. If fan-out is low it indicates unnecessary intermediate modules. If fan-out is very high, then too much detail has been introduced too soon.
Module-interface consistency -- The task of the module and parameters should be consistent. There should be no extra tasks performed by the module.
Restrictive module -- Constraints should be built into the module. Example: if the module is to edit 80 character string, then the constraints should be coded into the module.
Scope of effect -- the collection of all modules that contain processing that is dependent on the result of a decision.
Span of control -- includes the module itself as well as all of its subordinate modules at any lower levels in the hierarchy.
The scope of effect should be contained within the span of control. The span of control forms the boundary within which all scope of effect modules should reside.