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.
Why break a problem into parts? Experimentally it is proven that:
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:
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 ...
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:
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:
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):
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.