Google Translate Widget by Infofru

Author Site Reviewresults

Structured Design

In programming and algorithm design, the Structured Design aims to elaborate algorithms that comply with the modularity property, for this, given a problem that is intended to solve by the elaboration of a computer program, it is sought to divide said program into modules according to the principles of Design of Decomposition by successive refinements, creation of a modular Hierarchy and elaboration of Independent modules.

Stages of Structured Design


Why break a problem into parts? Experimentally it is proven that:

  • A complex problem costs more to solve than a simpler one (of Perogrullo).
  • The complexity of a global problem is greater than the value of the complexities of each of its parts separately.

Accordingly, it is worth the effort to divide a large problem into smaller subproblems. If the goal is to develop a program to solve that large problem, each (less complex) subproblem can be solved by a relatively easy to implement (sub-algorithm) module (rather than the non-divided global program). Now the question is how to perform the decomposition ?; performing a top-down downward study that takes us from the conception of the global problem (program or algorithm) to identifying its parts. This technique is repeated by applying a so-called refinement strategy proposed by computer science expert Niklaus Wirth, which consists precisely in re-applying the top-down downward study to each subproblem again and again until it obtains sufficiently small subproblems can be solved by modules that meet, as far as possible, the desirable characteristics in a module in the programming area. In the words of Niklaus Wirth himself:

  • At each step (refinement), one or more given program instructions are broken down into more detailed instructions. This successive decomposition or refinement of specifications ends when all instructions are expressed in terms of the computer used or the programming language ...
  • As tasks are refined, data can also be refined, decomposed, or structured, with the natural refinement of program and data specifications in parallel.

Each step of refinement involves some design decisions. It is important that the programmer is aware of the underlying criteria (in the design decisions taken) and the existence of alternative solutions ...

Successive Refinement Problem

When to stop the refinement ?. Excessive refinement could result in such a large number of modules that would make decomposition impractical. These criteria will be taken into account in order to stop decomposing:

  • When there are no well defined tasks.
  • When the interface of a module is as complicated as the module itself

Hierarchy of Modules

This is a direct consequence of the decomposition of the problem through successive refinements, the result will be a set of modules layered as a pyramid where at the top there will be a single module that will represent the overall program and at the lower levels will appear the resulting modules of successive divisions.

In the end, a pyramidal structure must be obtained where the modules of the higher levels are responsible for the tasks of coordination, application logic and manipulation of the lower modules; these others must perform calculations, processing and input / output information.


Evaluating the Design

To evaluate or determine how well a structured design is used the concepts of coupling and cohesion; these are closely related to each other, so much so that one can hardly vary one without affecting the other. It can also be said that these concepts are not measures that can be quantified numerically, but rather are qualitative magnitudes. The concepts of fan-in and fan-out are also considered.


It is defined as the degree of interdependence between the different modules of a program; it is desirable that this interdependence be as small as possible, ie a low coupling. Coupling levels, ordered from less (more desirable) to greater (less desirable) are:

Normal coupling.- One module calls another at a lower level and only exchanges data (input / output parameters). Within this type of coupling we can find 3 subtypes, depending on the data that the modules exchange:

  • Data coupling: Modules communicate via parameters.
  • Coupling of mark or by stamping: The modules pass data with registration structure. It is not very desirable if the receiving module only requires some of the data passed to it.
  • Control coupling: The data exchanged between the modules are controls. Because in this subtype one module controls the execution of the other, it is not a good coupling, since it prevents them from being totally independent.
  • Common Link.- Two modules access the same common resource, typically shared memory, a global variable or a file. A variant of this type of coupling is the external coupling:
  • External coupling.- The modules are connected to external components. For example, I / O devices, communications protocols ... etc.
  • Content coupling.- Occurs when a module needs access to a part of another module.


It is defined as the measure of force or functional relationship existing between the sentences or groups of sentences of the same module. A cohesive module will execute a single simple task interacting very little or nothing with the other modules of the program. It is intended that the modules have a high cohesion.

In the structured design we can find the following 7 types of cohesion (from the best or most desirable to the least recommended):

  • Functional cohesion: The elements of the module are related in the development of a single function.
  • Sequential Cohesion: A module performs different tasks in sequence, so that the inputs of each task are the outputs of the previous task. It is not bad cohesion if the tasks involved are not very complex and require few lines of code.
  • Communicational Cohesion: The module performs parallel activities using the same input and output data. As in the previous case, it is not a bad kind of cohesion if the tasks are relatively simple.
  • Procedural Cohesion: The module has a series of functions related by a procedure done by the code (as a library). It is similar to the sequential, but may include the step of controls. It will be desirable for the functions to be related or to perform tasks within the same scope (eg the string.h library of C contain functions for operating strings).
  • Temporal cohesion: The elements of the module are involved in activities related to time.
  • Logical Cohesion: The activities carried out by the module have the same category. That is, it is as if they have independent parts within the same module.
  • Casual or coincident cohesion: The elements of the module contribute to activities relating to one another in a non-significant way. This type of cohesion violates the principle of independence and black box of the modules.

Fan-In and Fan-Out

In addition to the two concepts above, the fan-in and the fan-out of the modules must be taken into account to guarantee the quality of the design.

  • Fan-In: Also called degree of absorption. It is the number of immediate superordinates that the module in question has. It is convenient to maximize the fan-in during the design process, as each multiple fan-in instance indicates that code duplication has been avoided.
  • Fan-Out: Also called control dissemination. It is the number of immediate subordinates that the module in question has. It is advisable not to have a fan-out neither very high nor very low, since that is a possible indicator of a poor design. If it is not possible to avoid it, a low fan-out rather than a high one is preferable.


We have 73 guests and no members online