Design Guidelines

Section 0: Module Objectives or Competencies

Section 1: Design Guidelines

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 about 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.
• 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.
• Three to nine is preferred.

Modules with restrictions

• Constraints/restrictions should be built into modules.
• Example: Restrictions on a username field may include minimum username length, maximum username length, Configuration of valid characters for usernames, only allow lower case characters for usernames.

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.

Section 2: Structured Design Heuristics

What is a heuristic?

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 that 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.

Parts that are related to one another should be grouped together, and unrelated parts should be distanced.

Section 3: Refactoring

While refactoring is generally encountered most often in Agile development, it is closely related to the design guidelines.

Code Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior (link).

• Un-refactored code tends to rot.
  • Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, way too many responsibilities per method or class, duplicate code, and many other varieties of confusion and clutter.
  • Every time we change code without refactoring it, rot worsens and spreads.
  • Refactoring code ruthlessly prevents rot, keeping the code easy to maintain and extend.

The following are claimed benefits of refactoring (link):

• refactoring improves objective attributes of code (length, duplication, coupling and cohesion, cyclomatic complexity) that correlate with ease of maintenance
• refactoring helps code understanding
• refactoring encourages each developer to think about and understand design decisions, in particular in the context of collective ownership / collective code ownership
• refactoring favors the emergence of reusable design elements (such as design patterns) and code modules

It is important to remember that refactoring does not not change the external behavior of the modules.

• The process involves an iterative cycle of making a small program transformation, testing it to ensure correctness, and making another small transformation.
• Through many small steps the program moves from where it was to where it should be.